An Exploration of Scope Creep
Paige Booker
November 2015
Introduction
The term scope creep evokes many feelings in project managers and team members. While some embrace the proposed changes by accepting it as a project norm, others are hard pressed to avoid it altogether. While project management is often taught as a science, many would argue that its real life application is certainly an art. While several methodologies (i.e. Waterfall, Agile, Extreme) provide guidance along the way, there are a multitude of factors that may impact the project throughout its lifecycle. Scope creep is definitely one of those things. Even with careful planning and risk assessment, scope creep has the potential to - well, creep into a project at any time causing consequences that range from tiny ripples to a major tsunami.
There are some projects that are just chaotic from inception, maybe due to resource constraints or unknown solutions (think prescription drug development). Those projects are a topic for another day. In this case, when given the chance to properly plan, allocate resources, develop schedules, and assess risk for a given project, there is a certain hope that a project has been set up for success.
In systems analysis, the software development life cycle has been laid out as plan, design, implement, and maintain (Kaur, et al., 2015). After several meetings with a client and analysis of its current systems, the project has moved into the design phase. A solid project team has been formed with all of the strengths required for the project, everyone is aware of the critical path, codes are being tested, retested, and documented.
The project is under way and the client is excited about the new server that will greatly increase enterprise-wide networking issues and productivity. The client is so excited about the upcoming changes and possibilities that there has now been a request to incorporate a new feature that is now available as a result of the upgraded server. This, ladies and gentlemen, is scope creep.
By definition, scope creep occurs when additional unplanned work has been added to a project once it is already under way due to a perceived shifting focus (Crumrine, et al, 2005). Taking it a step further, Villanova University’s website adds scope creep occurs when changes occur after design has been approved “without providing equivalent increases in budget, time, and/or resources.” Regardless to whether the newly requested feature is small or large, it was not planned. If a few extra lines of codes can be added or if the current code needs to be entirely rewritten, regardless as to whether this takes thirty minutes or six months, these changes will cut into resources that have already been allocated elsewhere or may even require additional resources in the form of time, money, labor, and/or additional hardware or software and potentially sacrific the quality of the project.
Before continuing with any further discussion of scope creep, it is important to understand and acknowledge project scope. A project scope is critical to any project, without regard to industry. The project scope provides parameters for the project by detailing what the project entails, as well as lists the project exclusions which are equally as important (Rahmesh, et al, 2012). The existence of a clearly defined scope creates an understanding for all parties involved with the project and is crucial to project success and directly related to scope creep. It could be argued that without a project scope, there is no scope creep. Alternatively, it could be argued that without a project scope, there is almost surely project chaos.
An ideal project scope should be comprehensive enough to act as a contract or at least be incorporated into the contract documents. In order to produce the project scope, the following should be included:
Project Objectives (brief overview)
Deliverables
Milestones
Technical Requirements
Limits and Exclusions
What Causes Scope Creep
Scope creep is usually a “subtle process that starts with small adjustments,” (Techopedia.com) so there are many ways for scope creep to infiltrate a project. Some project managers choose to manage scope creep, while others choose to avoid it altogether. (This will be discussed shortly.) Either way, it is important to be aware of the sources of scope creep so that it can be handled accordingly.
Fault is often placed squarely on the shoulders of a client as the direct source of the additional request(s). However, that is not entirely true. The project team also bears responsibility for scope creep invasions on projects. Communication is key (Patterson, 2010) and lends it hand to both parties contributing to the dreaded phenomenon of scope creep.
Project scope can see an influx when clients do not fully understand the intended purpose of a project. With a proper scope in place, it is assumed that all parties are in agreement regarding what exactly the project entails. However, that assumption would be incorrect. Though armed with good intentions, many clients sign contracts or agree to project scopes without grasping the concept of the project in its entirety. Agreements may be rushed under time or budget constraints. Or as typical in life, clients (and everyone else, for that matter) often agree to terms without really reading them through.
While it is certainly a client’s responsibility to read through project scopes and/or agreements, a project manager should ensure that the client also understands. In a world where the majority of IT projects are not deemed successful (according to the Standish Group’s 2009 ChAOS Summary), IT professionals and project managers must take a more active role in turning these statistics around. One easy way to accomplish this is to begin with making sure clients are on board with projects.
Speaking of being on board, clients can also contribute to scope creep when everyone is not on board with the project internally. According to Techopedia.com, scope creep can occur when there are “competing forces” within an organization that may or may not agree on a best practice approach to the project. For example, in the case of a new server implementation, a superintendent may think the best solution would be to move to a virtual server to increase speeds in the field. Meanwhile, the front office manager may believe the best solution is to incorporate the existing server in a way that can handle a new software that can be placed on a physical or virtual server. These are two competing forces as the superintendent is more interested in the performance of the server when outside of the office, and the office manager is more concerned with the budget of the project and the time it would take to implement the new server and train the entire organization on new procedures. When the office manager is responsible for providing information to the systems analyst, there may be additional features or relevant information that he/she misses that is relevant to the field superintendent (Damian, et al, 2003). If discovered after the initial design phase of the project, this information will be relayed to the project manager at a later date, usually as a feature the client must or would love to have, contributing the project gradually expanding, otherwise known as scope creep.
Alternatively, the field superintendent and front office manager may both be a part of an internal team responsible for the implementation of the new server. Through collaboration, they are able to determine what they feel are the organization’s objectives with the new server and internally take charge of the project on the client’s side. Collaboration is ideal, but may still give way to scope creep if all appropriate organization’s members are not involved in the project from its inception. Suppose the client’s internal team has been empowered to make critical financial decisions regarding the project, but does not contain any C-suite members of any kind. After the project is underway, it may be realized that though the server selected works for the organization’s current workload, it does not align with executive’s future goals for the organization within the next few years. At this point, additional storage, features, or capabilities for the server may be requested or an entirely different server may be necessary to meet future goals. This is scope creep.
In either case, clients have introduced scope creep into the project. Of course, they do not submit the requests to the project manager with a subject line that reads Scope Creep. In the eyes of the client, the requests typically come from a place of wanting to see the project succeed or improve, and many times do not consider the ramifications this may have on the project team or the effects on resources such as time and budget that has already been allotted for the project.
Clients may not understand that projects rarely work in a vacuum. While a new accounting software may only seem relevant to the accounting department, it would be flawed to discount the many internal users of the accounting information. In the case of the construction organization, the C-suite members must be able to access dashboards and or reports that give an overview of the company. Field teams must be able to keep track of the job costs related to various past and present construction projects. The exclusion of members outside of the accounting department could have minor or major effects as to how others access the information or perform their own job duties.
In either instance, project managers can act as a great tool to ensure the proper stakeholders are involved with the project from the very beginning (Bourne, et al., 2008). When it comes to technology, clients rarely know what it is they truly desire. As a systems analyst, evaluating the entire system, including people, processes, and technology is crucial. As Susan Hodges (2015) states, “Seek the input of every employee in every department, and pave the road to project completion with pure gold.” Understanding the client’s processes and how departments are connected allows for the development of a project that will fit the needs and requirements for all invested and affected by the project.
Among other things, the industry itself can be the cause for scope creep. Technology is ever-evolving and rarely ever “complete.” Depending on the length of a project, new or updated software, hardware, features, capabilities, etc. may present new opportunities related to the scope of the project or attract the interest of the client. In such cases, it is important to understand how to manage or avoid scope creep.
Understanding scope creep is essential to a project because it impacts client satisfaction (Corlane et al, 2010) and allocated resources. Both of these directly tie into the project’s success. In an industry where only 32% of projects are hailed as successful by the Standish Group, it necessary for project managers to be aware of the effects of scope creep and its impact on projects.
Initial project requirements (found in the project scope and/or contract documents) are used to design both the physical product or service and also the project itself. Those project requirements are used to assemble the appropriate project team and identify milestones and event predecessors, all while maintaining a budget agreed upon with the client. The success of the project is literally depends on whether the project was delivered as promised - on schedule and within budget (Corlane, et al, 2010).
When clients suggest additional features or slight tweaks to the project, this affects the balance of current resources already designated for other items. By cutting into cost, quality, and time, no matter how large or small, the bottomline of the project is affected (Bellenger, 2003).
At the same token, the project is not satisfactorily completed in the client’s eyes until all project requirements have been met. These requirements may include features and capabilities that were assumed and/or thought to be implied, as well as the agreed upon requirements. Outside of the deliverables of the project, there may also be assumed support or services provided by the project manager. The client’s perception is reality so communication is essential between the client and project manager to minimize the variation between expected and actual outcomes of the project.
Scope creep is considered to be “one of the most important factors” that influences the success of a project (Madhuri, et al, 2014). It impacts the internal resources and the external perception of a client as to whether or not the project was completed successfully. Therefore, it is important to understand and address potential scope creep on a project.
Thought to be an unpredictable, but regular happenstance on projects, many project managers choose to manage scope creep rather than try to avoid it. A few ways to manage scope creep are to accept it, document changes, and price correctly.
Whenever there is change, the first step is always acceptance. Do not allow negative thinking to take over or disrupt a relationship with a client. There is no refuge in wallowing in disappointment regarding upcoming changes to the project. Embrace the change, rework plans, and forge ahead. A negative attitude can kill any project or outcome in life.
When managing scope creep, pricing should be a factor and could go one of two ways. One method would be to use a zero sum operation (Clark, 2014) where the scope never really grows. In exchange for adding one feature, another feature is removed from the scope. Another alternative is to create “under-way” pricing for additional features to be added once the project is under way. For instance, programming labor hours may normally be charged at $200/hr, but once the project is started, additional programming hours needed as a result of expansion to the project will run the customer $350/hr. In both cases the goal is to have the client consider if the changes are really necessary and/or could be sidelined for a future project. Both methods cause the client to make an informed decision, but could also contribute to negative feelings toward the project or project manager. This tool would have to be used carefully.
Another way to manage scope creep it to formally document changes as they arise. Before moving ahead with requested changes, even small ones, create a document or log that contains all changes that must be signed off on by client and project manager. The document should detail all of the “implications of change” especially time needed to implement, costs, and effects on current schedule (Stachowiak, 2014). Acknowledgement of the new terms should help with keeping the client happy and aware of the progress of the project. Similar to agreement on project scope both client and project manager share the responsibility in making sure both parties are on the same page. For the sake of project success, the project manager should be willing to go the extra mile to ensure the clients truly understands the impact of growth in the project scope.
One consideration that has not yet been made is that scope creep does not have to be accepted on any project. Keeping the client happy does not mean that every demand or request must be met. Scope creep can be avoided by prohibit gold plating, understand the client’s objectives, and be empowered to say no.
Gold plating is the practice of over-delivering “by members of the software development team to over-deliver on the scope and add features” (Clark 2014). According to the University Alliance at Villanova, project teams may gold plate under the “belief that value is being added”, however in reality, consumption of project resources does not guarantee “increased customer satisfaction.” Gold plating is a self-imposed or voluntary scope expansion on the part of the project team and should be avoided because avoiding scope creep protects the bottom line (Bellenger, 2003).
Another way to avoid scope creep is to understand the client’s objectives and intended outcomes for the project (Ewer, 2015). In the case of the client who wants a new server, the project manager should do due diligence to understand why. The result should be an outcome based objective such as:
increasing network capacity by 30% ,
purchasing new accounting software to improve job accounting processes and reporting, or
increase connectivity for field supervision to access and edit organization documents when outside of the home office.
Project managers should help clients focus on the “why” of the project (Hodges, 2015), rather than the “what.” Clients may try to direct project managers to the product or service they desire, but may not really know “what” that is.
Instead, clients typically know what outcomes they would like the project to produce which provides the “why” aspect of the project. For a project manager, focusing on the “what” gives way to vague project scopes, whereas focusing on the “why” helps create strong project requirements that can be used to create a strong project scope and/or contract documents. If the true complexity of the project is understood from the beginning, it is much easier to outright avoid scope creep as the scope should be tailored to the client’s true needs (Villanova’s University Alliance, 2015).
Last but not least, one way to avoid scope creep is to say no (Clark, 2014). Pretty simple, right? Of course not! In order to say no to clients who insist on increasing the size of the project, project managers must first be empowered by his/her own organization to challenge the notion that the customer is always right. Secondly, the project manager must be willing to be critically honest with clients regarding the processes and features needed to reach project goals. (Ewer, 2015) Of course client satisfaction is still a factor. There may be an opportunity to regulate additional requests to another phase or project at a later date or the project manager may have to break the news that the changes or features requested are simply unnecessary or infeasible. As always, communication will be key. The rejection of a client’s request does not have to come as a blow to the client’s ego or satisfaction of the project. With a detailed project scope in hand and effective communication, clients should be able to take away the reasons why the scope cannot be increased on the project and respect it. With all of these items in place, saying no to a client will help prevent scope creep on the project.
Pros and Cons of Scope Creep
The word creep in itself has its own negative connotation associated with it, but that does not have to mean that scope creep is exclusively bad. Sure, a huge con is that scope creep often contributes to “excessive costs, delays, project failures, and a lot of additional work,” (Tyson, 2011) but that is not always the case.
For a client who gets all needs and desires incorporated into a project(possibly at a bargain rate), scope creep is a positive thing. To the organization who has satisfied and retained its client for future projects, the scope creep is outweighed by the positive effects in the end (Tyson, 2011). Some organization treasure this qualitative benefit. Other organizations recognize the creativity among the project team when allowed to gold plate on the project as deemed fit. In 2006, Dr. David Hillson likened scope creep to opportunity management, giving the term a complete connotation makeover.
Still yet, there are horror stories such as that of IT Manager Tim Malone’s costly experience while working for a private jet charter management company back in 2008. The exclusion of the proper stakeholders at the project’s inception and lack of communication turned this company’s oversight of a telecommunications issue into a $60,000+ scope creep issue! Searching the internet and archives, stories like Tim’s are much more common than those of anyone praising the pros of scope creep. In fact, Carrie Dils even wrote a song about the perils of scope creep.
Not all scope creep drives back milestone dates or requires an additional sixty (60) hours of code to be written. Alternatively, some additional project specifications are the source of project failure or overrun budgets by several thousands of dollars! Like everything else, scope creep is neither all bad or all good; it’s more so subjective, but more often than not, impedes the progress of a project.
Scope creep is not a necessary evil and not necessarily evil. Excellent project management and effective communication and trust between all project parties is key in managing or avoiding scope project on a system analyst project. When considering or fearful of scope creep, keep these three (3) things in mind:
Have a project scope that is simplistic enough to understand, but comprehensive enough to serve as a contract document
Understand the causes (and easy solutions) of scope creep
Be aware of tools to manage or avoid scope creep
Fulfilling client’s needs and executing successful IT projects is extremely important. By keeping these three things in mind, scope creep will only be as small or large of a problem as allowed. Scope creep certainly does not have to ruin a project.
Scholarly Sources
Bellenger, Lynn G. "Avoiding Scope Creep Protects the Bottom Line."
ASHRAE Journal 45.10 (2003): 58.
ProQuest. Web. 11 Nov. 2015.
Bourne, Lynda, and Derek H. T. Walker. "Project Relationship Management and the Stakeholder Circle(TM)."
International Journal of Managing Projects in Business 1.1 (2008): 125-30.
ProQuest. Web. 11 Nov. 2015.
Corlane Barclay, Kweku-Muata Osei-Bryson, Project performance development framework: An approach for developing performance criteria & measures for information systems (IS) projects, International Journal of Production Economics, Volume 124, Issue 1, March 2010, Pages 272-292, ISSN 0925-5273, http://dx.doi.org/10.1016/j.ijpe.2009.11.025.
(http://www.sciencedirect.com/science/article/pii/S0925527309004289)
Crumrine, Tim, et al. "Interface Management for Subsea Sand Control Completions."
Offshore 10 2005: 88,88,90,92.
ProQuest.Web. 12 Nov. 2015 .
E. Damian, D., & Zowghi, D. (2003). RE challenges in multi-site software development organisations. Requirements Engineering, 8(3), 149-160. doi:10.1007/s00766-003-0173-1
Hodges, Susan L. "10 STEPS to IT Success."
Equipment Leasing & Finance 31.5 (2015): 24,26,28,30.
ProQuest. Web. 15 Nov. 2015.
Kaur, Anureet, and Kulwant Kaur. "Suitability of Existing Software Development Life Cycle (SDLC) in Context of Mobile Application Development Life Cycle (MADLC)."
International Journal of Computer Applications 116.19 (2015)
ProQuest.Web. 13 Nov. 2015
Madhuri, K. L., Jawahar J. Rao, and Suma V. "Effect of Scope Creep in Software Projects Aeuro]" its Bearing on Critical Success Factors."
International Journal of Computer Applications 106.2 (2014)
ProQuest. Web. 15 Nov. 2015.
Patterson, Jessica. "Communication is Key to Good Project Management."
Journal of Commerce.46 (2010): 1.
ProQuest. Web. 20 Nov. 2015.
Rahmesh, S. P., and B. Madhavan. "Scope Creep, Scrap & Churn are NOT SINS in Requirements Engineering."
Drishtikon : A Management Journal 3.1 (2012): 174-90.
ProQuest. Web. 16 Nov. 2015.